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Foreword 



This Technical Specification has been produced by the 3rd Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the architecture enhancements for Single Radio Voice Call Continuity (SRVCC) 
between E-UTRAN access and 3GPP2's IxCS, and between E-UTRAN access and 3GPP's UTRAN/GERAN accesses 
and between UTRAN (HSPA) access and 3GPP's UTRAN/GERAN accesses, for Circuit Switched (CS) calls that are 
anchored in the IMS. 

This document will not describe 3GPP2 functional entities. However, interfaces between both 3 GPP and 3GPP2 
functional entities are described in this specification. 

SRVCC from E-UTRAN access to 3GPP2 IxCS is covered in this specification, including the handling of IMS 
emergency call continuity. Handling of non- voice component and SRVCC from 3GPP2 IxCS to E-UTRAN direction is 
not specified in this release. 

SRVCC from E-UTRAN/UTRAN (HSPA) access to 3GPP UTRAN/GERAN CS accesses for voice calls that are 
anchored in the IMS, as well as the coordination between the SRVCC for voice call and the handover of non- voice PS 
bearers and the handling of IMS emergency call continuity, are covered in this specification. The handover of non- voice 
PS bearer from E-UTRAN is specified by the procedures defined in TS 23.401 [2], TS 23.060 [10], TS 25.413 [11] and 
TS 43.129 [12]. The handover of non voice PS bearer from UTRAN (HSPA) is specified by the procedures defined in 
TS 23.060 [10], TS 25.413 [11] and TS 43.129 [12]. Handling of SRVCC from 3GPP UTRAN/GERAN CS accesses to 
E-UTRAN/UTRAN (HSPA) direction is not specified in this release. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

IxCS: The 3GPP2 legacy circuit switched signalHng system as defined in 3GPP2 X.S0042-0 [4]. 
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3GPP SRVCC UE: A 3GPP SRVCC UE is a UE enhanced for IMS Service Continuity with the additional UE 
capabiHties described in this specification for SRVCC between E-UTRAN and 3 GPP UTRAN and / or between E- 
UTRAN and 3GPP GERAN and / or between UTRAN (HSPA) and 3GPP UTRAN and 3GPP GERAN. 

Emergency Session Transfer Number for SR VCC (E-STN-SR): see TS 23.237 [14]. 

Single Radio Voice Call Continuity: Voice call continuity between IMS over PS access and CS access for calls that 
are anchored in IMS when the UE is capable of transmitting/receiving on only one of those access networks at a given 
time. 

Session Transfer Number for SR-VCC (STN-SR): see TS 23.237 [14]. 

Correlation MSISDN: An MSISDN used for correlation of sessions. See TS 23.003 [27] for more information. 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

SRVCC Single Radio Voice Call Continuity 

IxCS IWS Single Radio Voice Call Continuity Interworking solution Function for 3GPP2 IxCS 

S AI Serving Area Identity as defined in TS 25 .4 1 3 [ 1 1 ] 

C-MSISDN Correlation MSISDN 



4 High level Principles and Concepts 

4.1 High level Principles 

4.1 .1 Architectural Principles for 3GPP2 IxCS SRVCC 

The solution for SRVCC fulfils the requirements of TS 22.278 [9] and the following architectural principles: 

1. The solution shall allow coexistence and be compatible with the IxCS procedures specified in the 3GPP2 VCC 
specification, X.S0042 [4]. 

2. The solution shall not require UE with multiple RATs capability to simultaneously signal on two different RATs. 

3. The solution shall be transparent to E-UTRA only terminal or network. 

4. The solution shall minimize the coupling between the E-UTRAN and the 3GPP2 access. In particular, the 
solution shall allow the cdma2000 IxRTT specification to evolve without necessitating a modification to the E- 
UTRAN specifications. 

5. RAT change and domain selection should be under network control. 

6. In roaming cases, the Visited PLMN should control the RAT change and/or domain selection while taking into 
account any related HPLMN policies. 

7. The solution shall not impact cdma2000 RAT. 

8. The solution shall not impact cdma2000 CS CN. 

9 All IMS sessions that may be subject to SRVCC shall be anchored in the IMS (VCC Application). 
10. When SRVCC is deployed, QCI=1: 

- shall not be used for IMS sessions that are not anchored in the IMS (VCC Application); and 

- shall only be used for the voice bearer. 
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4.1 .2 Architectural Principles for 3GPP UTRAN/GERAN SRVCC 

The solution for SRVCC fulfils the requirements of TS 22.278 [9] and the following architectural principles: 

1. The solution shall allow coexistence and be compatible with TS 23.292 [13] and TS 23.237 [14]. 

2. The solution shall not require UE with multiple RATs capability to simultaneously signal on two different RATs. 

3. RAT change and domain selection should be under network control. 

4. E-UTRAN/UTRAN (HSPA) to UTRAN/GERAN handover for SRVCC is triggered by the same radio handover 
conditions and mechanisms as for an E-UTRAN/UTRAN (HSPA) to UTRAN/GERAN PS handover. 

5 All IMS sessions that may be subject to SRVCC shall be anchored in the IMS (SCC AS). 

6. When SRVCC is deployed, QCI=1 / traffic-class conversation with source statistics descriptor =" speech": 

- shall not be used for IMS sessions that are not anchored in the IMS (SCC AS); and 

- shall only be used for the voice bearer. 

NOTE: The UE may have multiple voice media streams that are multiplexed over a single voice (e.g. QCI=1) 
bearer. Selection of the voice streams for SRVCC by the SCC AS is as specified in TS 23.237 [14]. 

4.2 Concepts 

4.2.1 E-UTRAN and 3GPP2 1xCS SRVCC 

For SRVCC-capable UEs, the call is always anchored at the VCC AS in the 3GPP2's IMS. The 3GPP2 IxCS IWS 
enables a single radio UE to communicate in parallel both with the source system and the target system. From VCC 
perspective, this mechanism minimizes the voice gap by supporting the transport of signalling for establishment of the 
target CS access leg while the terminal is connected to the source PS access network. 



Originating Side 



1xCS 

SRVCC 

UE 



E-UTRAN 



EUTRAN/EP3 tunnelling 



1xCS signalling 
messages tunnelled 
across EUTRAN / 
EPS 




S102 tunnelling 



1xCS signalling 
messages tunnelled 
inside S102 protocol 



1xCS 
IWS 



Target Side 



1xRTT 
MSC 



Registration and 
Authorization if needed 



CS Call setup procedures 



Towards 
VLR/HLR 



Call terminated 
> at VCC AS 



VCC AS STARTS 

VCC Domain Transfer 

PROCEDURES 



A1 messages 



Figure 4.2.1-1 : Transport of 3GPP2 IxCS signalling messages for preparation of the CS access leg in 

the target system 

The S102 reference point is used to convey 3GPP2 IxCS signalling messages between the MME and 3GPP2 IxCS 
IWS. These Ix CS signalling messages are actually exchanged between the UE and the 3GPP2 IxCS IWS, and S102 is 
only one link in the overall UE-lxCS IWS tunnelling path. On the remaining portion of the tunnelling path, the 3GPP2 
IxCS signalling messages are encapsulated in E-UTRAN/EPS tunnelling messages (UE-MME). 
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4.2.2 E-UTRAN and 3GPP UTRAN/GERAN SRVCC 

For facilitating session transfer (SRVCC) of the voice component to the CS domain, the IMS multimedia telephony 
sessions needs to be anchored in the IMS. 

For SRVCC from E-UTRAN to UTRAN/GERAN, MME first receives the handover request from E-UTRAN with the 
indication that this is for SRVCC handling, and then triggers the SRVCC procedure with the MSC Server enhanced 
with SRVCC via the Sv reference point if MME has SRVCC STN-SR information for this UE. MSC Server enhanced 
for SRVCC then initiates the session transfer procedure to IMS and coordinates it with the CS handover procedure to 
the target cell. MSC Server enhanced for SRVCC then sends PS-CS handover Response to MME, which includes the 
necessary CS HO command information for the UE to access the UTRAN/GERAN. 

Handling of any non- voice PS bearer is done by the PS bearer splitting function in the MME. MME starts the handover 
of non-voice PS bearer during SRVCC procedure based on the information received from E-UTRAN. The handover of 
non-voice PS bearer(s), if performed, is done as according to Inter RAT handover procedure as defined in 
TS 23.401 [2]. The MME is responsible to coordinate the Forward Relocation Response from PS-PS handover 
procedure and the SRVCC PS to CS Response. 




Figure 4.2.2-1 : Overall high level concepts for SRVCC from E-UTRAN to UTRAN/GERAN 

4.2.3 UTRAN (HSPA) to 3GPP UTRAN/GERAN SRVCC 

For facihtating session transfer (SRVCC) of the voice component to the CS domain, the IMS multimedia telephony 
sessions needs to be anchored in the IMS. 

For SRVCC from UTRAN (HSPA) to UTRAN/GERAN, SGSN first receives the handover request from UTRAN 
(HSPA) with the indication that this is for SRVCC handling, and then triggers the SRVCC procedure with the MSC 
Server enhanced with SRVCC via the Sv if SGSN has STN-SR information for this UE. MSC Server enhanced for 
SRVCC then initiates the session transfer procedure to IMS and coordinates it with the CS handover procedure to the 
target cell. MSC Server enhanced for SRVCC then sends PS-CS handover Response to SGSN, which includes the 
necessary CS HO command information for the UE to access the UTRAN/GERAN. 

Handling of any non voice PS bearer is done by the PS bearer splitting function in the SGSN. SGSN starts the handover 
of non voice PS bearer during SRVCC procedure based on the information received from UTRAN (HSPA). The 
handover of non voice PS bearer(s), if performed, is done as according to Inter/Intra RAT handover procedure as 
defined in TS 23.060 [10] and TS 25.413 [11]. The SGSN is responsible to coordinate the Forward Relocation 
Response from PS-PS handover procedure and the SRVCC PS to CS Response. 
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UE 



UTRAN 



SGSN 



MSC Server 



Target 
UTRAN/GERAN 



3GPP IMS 



Measurement 
Reports 



Handover to UTRAN/GERAN 
required 



^e- 



Handover CMD 



Handover 
execution 



Initiates SRVCC for voice component 



I 



' Handles PS-PS HO for 
, non-voice if needed 




OS handover preparation 



IMS Service Continuity Procedure 



To UTRAN(HSPA) 
^ — I Coordinates SRVCC 
and PS HO response , 



CS HO response to SGSN 



Figure 4.2.3-1 : Overall high level concepts for SRVCC from UTRAN (HSPA) to UTRAN/GERAN 

4.2.4 SRVCC for IMS emergency sessions 



4.2.4.1 



E-UTRAN/UTRAN (HSPA) to 3GPP UTRAN/GERAN 



UE initiates the IMS emergency session as specified in TS 23.167 [28], TS 23.401 [2] for E-UTRAN or TS 23.060 [10] 
for UTRAN (HSPA). For facilitating session transfer (SRVCC) of the IMS emergency session to the CS domain, the 
IMS emergency session needs to be anchored in the serving IMS (i.e., in visited PLMN when roaming) as specified in 
TS 23.237 [14]. 

The E-UTRAN initiates the SRVCC procedure as specified for regular Voice over IMS session. The MME is aware that 
this is an emergency session and sends an indication to the MSC Server enhanced for SRVCC. MSC Server then 
initiates the IMS service continuity procedure with the locally configured E-STN-SR to the serving IMS. When 
handover of the emergency session has been completed, the MME/SGSN or the MSC server may initiate location 
continuity procedures for the UE as defined in TS 23.271 [29]. 

NOTE: Procedure for multiple E-STN-SRs configuration is not defined in this release. The serving PLMN is 
assumed to have a single logical EATF (i.e. single 14 in TS 23.237 [14]. 
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Figure 4.2.4.1-1 : Overall high level concepts for SRVCC IMS emergency session with E-STN-SR 



4.2.4.2 



E-UTRAN to 3GPP2 1xCS 



The UE initiates emergency session over E-UTRAN as specified in TS 23.167 [28], TS 23.401 [2], upon detecting 
handover is required from E-UTRAN to CDMA Ix, the SRVCC emergency procedure apply. To support handover of 
emergency session the network is aware that the UE and core network support SRVCC and has information to identify 
Emergency session. When handover of the emergency session has been completed, the MME or the IxRTT side may 
initiate location continuity procedures for the UE as defined in TS 23.271 [29]. 
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Figure 4.2.4.2-1 : E-UTRAN to 3GPP2 IxCS 



4.2.4.3 



SRVCC in Limited Service Mode 



4.2.4.3.1 



E-UTRAN/UTRAN (HSPA) to 3GPP UTRAN/GERAN 



In order to support SRVCC emergency session domain transfer for UEs in Limited Service Mode (e.g. UlCC-less), the 
MME/SGSN shall support Limited Service Mode UE emergency attach defined in TS 23.401 [2] and TS 23.060 [10] 
using unauthenticated IMSI or equipment identifier. 

When E-UTRAN/UTRAN determines that SRVCC is needed, the MME/SGSN invokes SRVCC procedures to the 
MSC Server including the UE's equipment identifier. The MSC Server will setup the call leg towards the EATF with 
the UE's equipment identifier. This procedure is defined in TS 23.237 [14]. 



4.2.4.3.2 



E-UTRAN to 3GPP2 1x08 



In order to support SRVCC emergency session domain transfer for UEs in Limited Service Mode (e.g. UlCC-less), the 
MME shall support Limited Service Mode UE emergency attach defined in TS 23.401 [2] using unauthenticated IMSI 
or equipment identifier. 

When E-UTRAN determines that SRVCC is needed, the MME invokes SRVCC procedures to the IxCS IWS including 
the UE's equipment identifier. 
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Architecture model and reference points 



5.1 



General 



The SRVCC Architecture for 3GPP2 IxCS reuses many existing elements in 3GPP2 X.S0042 [4] for 3GPP2 IxCS. 

The SRVCC Architecture for 3GPP UTRAN/GERAN reuses the session transfer function defined for IMS in 

TS 23.237 [14] for IMS service continuity. The MSC Server that is enhanced for SRVCC may also be enhanced for ICS 

as defined in TS 23.292 [13]. 

The overall model and impacts to the various elements is provided in the following clauses. 



5.2 



Reference architecture 



5.2.1 E-UTRAN and 3GPP2 1xCS SRVCC architecture 

This specification introduces an additional functional entity to those defined in the E-UTRAN architecture 
TS 23.402 [3], called Ix CS SRVCC interworking solution function (3GPP2 IxCS IWS), see figure 5.2.1-1. 

NOTE: The figure only shows the necessary components related to 3GPP2 IxCS IWS. 
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CUE 



S1-U 



■■■■Serving/PDN 
GW 



SIP signalling 
Bearer before HO 
Bearer after HO 



Tunnelled 1xRTT messages 



Figure 5.2.1-1 : SRVCC architecture for E-UTRAN to 3GPP2 IxCS 

5.2.2 E-UTRAN and 3GPP UTRAN/GERAN SRVCC architecture 

This specification introduces an additional function to those defined in the E-UTRAN architecture TS 23.401 [2] for 
SRVCC. This additional function is provided by the MSC Server (i.e., MSC Server enhanced for SRVCC). 

NOTE 1 : The following figure only shows the necessary components related to MSC Server enhanced with 
SRVCC. 
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MSC Server shown in the figure is enhanced for SRVCC. 

This architecture also applies to roaming scenario (i.e., S8, S6a are not impacted due to SRVCC). 

The MSC server enhanced with SRVCC may not be the final target MSC which connects to the target cell. 

Figure 5.2.2-1 : SRVCC architecture for E-UTRAN to 3GPP UTRAN/GERAN 



5.2.3 UTRAN (HSPA) and 3GPP UTRAN/GERAN SRVCC architecture 

This specification introduces an additional function to those defined in the UTRAN architecture TS 23.060 [10] for 
SRVCC. This additional function is provided by the MSC Server (i.e., MSC Server enhanced for SRVCC). 
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Figure 5.2.3-1 : SRVCC architecture for UTRAN (HSPA) to 3GPP UTRAN/GERAN witli Gn based SGSN 



ETSI 



3GPP TS 23.216 version 10.5.0 Release 10 



16 



ETSI TS 123 216 VI 0.5.0 (2013-01) 



UE 



Um/Uu 



Target 
UTRAN/GERAN 



lu-cs/A 



MSC Server 



lu-ps/GbN 



SGSN 



S16 



Sv 



SGSN 



5^fiH/fir 



UE 



Uu 



UTRAN 
(HSPA) 




HSS 




IMS 



S12 



Serving/PDN 
GW 




N0TE1 
NOTE 2 
NOTES 
NOTE 4 



The above figures only show the necessary components related to MSC Server enhanced with SRVCC. 

MSC Server shown in the above figures are enhanced for SRVCC. 

This architecture also applies to roaming scenario. 

The MSC server enhanced with SRVCC may not be the final target MSC which connects to the target cell. 



Figure 5.2.3-2: SRVCC architecture for UTRAN (HSPA) to 3GPP UTRAN/GERAN with S4 based SGSN 



5.3 



Functional Entities 



NOTE 1: 3GPP2 components are not described here. Please refer to 3GPP2 X.S0042 [4]. 

NOTE 2: IMS components are not described here. Please refer to TS 23.237 [14] and TS 23.292 [13]. 

5.3.1 3GPP2 1x CS SRVCC interworking solution function (1xCS IWS) 

3GPP2 IxCS IWS uses the S102 reference point to communicate with the MME and to transport 3GPP2 IxCS 
signalling messages to the SRVCC UE. The role of the 3GPP2 IxCS IWS is: 

- To be a signalling tunnelling end point towards the MME for receiving/sending encapsulated 3GPP2 IxCS 
signalling messages to/from the UE; and 

- To emulate a IxRTT BSS towards the IxRTT MSC (reference point Al as defined in 3GPP2 A.S0014 [20] 
between IxBS and MSC). 

5.3.2 MSC Server enhanced for E-UTRAN/UTRAN (HSPA) and 3GPP 
UTRAN/GERAN SRVCC 

In addition to the standard MSC Server behavior defined in TS 23.002 [15], an MSC Server which has been enhanced 
for SRVCC provides the following functions as needed for support of SRVCC: 

- Handling the Relocation Preparation procedure requested for the voice component from MME/SGSN via Sv 
reference point; 

- Behaving as MSC Server enhanced for ICS as defined in TS 23.292 [13] if supported and when ICS flag is 
received via Sv reference point is set to true and optionally if the MSC Server is configured to Imow that the 
VPLMN has a suitable roaming agreement with the HPLMN of the UE; 

- Invoking the session transfer procedure or emergency session transfer procedure from IMS to CS as according to 
TS 23.237 [14]; 

- Coordinating the CS Handover and session transfer procedures; 

- Handling the MAP_Update_Location procedure without it being triggered from the UE; 

- In case of an emergency session, conditionally sending a MAP Subscriber Location Report to a GMLC to 
support location continuity according to TS 23.271 [29]. 
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5.3.3 MME 

5.3.3.1 Interworking with 3GPP2 1xCS IWS 

5.3.3.1.1 Interworking with 3GPP2 IxCS IWS 

If the MME (operator) supports interworking to 3GPP2 IxCS, the MME shall follow the rules and procedures described 
in TS 23.402 [3] with the following additions and clarifications: 

- To be a signalling tunnelling end point towards the 3GPP2 IxCS IWS for sending/receiving encapsulated 3GPP2 
IxCS signalling messages to/from the UE, which are encapsulated in SI -MME SI Information Transfer 
messages (TR 36.938 [7]). 

- release of the E-UTRAN resources after SRVCC to the 3GPP2 IxCS is completed. 

- include information to enable 3GPP2 network to determine emergency session. 

insert the equipment identifier during the handover procedure for the case UE operating in limited service mode. 

5.3.3.1.2 Selection of 3GPP2 IxCS IWS 

The 3GPP2 IxCS IWS can be selected based on the local configuration in the MME taking into account the Reference 
CelllD received in the Uplink SI cdma2000 Tunnelling message, 

5.3.3.2 Interworking with 3GPP MSC Server enhanced for SRVCC 

5.3.3.2.1 Interworking with 3GPP MSC Server enhanced for SRVCC 

If the MME (operator) supports the interworking to 3GPP CS, the MME shall follow the rules and procedures described 
in TS 23.401 [2] with the following additions and clarifications: 

- Performing the PS bearer splitting function by separating the voice PS bearer from the non- voice PS bearers. 

- Handling the non- voice PS bearers handover with the target cell as according to Inter RAT handover procedure 
as defined in TS 23.401 [2]. 

- Initiating the SRVCC handover procedure for handover of the voice component to the target cell via the Sv 
interface and including an emergency indication if this is an emergency session. If there are multiple voice 
bearers and one of those is for IMS emergency session then MME shall only execute the SRVCC for emergency. 

NOTE: The UE may have 2 voice PS bearers if both emergency and normal IMS voice sessions are ongoing. 
Only the PS voice bearer associated with IMS emergency session will be executed for SRVCC. 

- Coordinating PS handover and SRVCC handover procedures when both procedures are performed. 

- Sending the equipment identifier to the MSC Server during the handover procedure for the case of UEs operating 
in limited service mode. 

- In case of an emergency session, conditionally sending a Subscriber Location Report to a GMLC to support 
location continuity according to TS 23.271 [29]. 

5.3.3.2.2 PS bearer splitting function 

The function identifies the voice PS bearer upon E-UTRAN to UTRAN/GERAN SRVCC and performs different 
handling of this bearer from the non- voice PS bearers (see detailed procedures in subsequent clauses). 

5.3.3.2.3 Selection of MSC enhanced for SRVCC 

The MSC enhanced for SRVCC can be selected based on DNS procedures (see TS 29.303 [33]) or local configuration 
in the MME. 
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5.3.3A SGSN 

5.3.3A.1 Interworking with 3GPP MSC Server enhanced for SRVCC 
5.3.3A.1 .1 Interworking with 3GPP IVISC Server enhanced for SRVCC 

If the SGSN (operator) supports the interworking to 3GPP CS, the SGSN shall follow the rules and procedures 
described in TS 23.060 [10] with the following additions and clarifications: 

Performing the PS bearer splitting function by separating the voice PS bearer from the non- voice PS bearers. 
VoIP is detected by traffic class=conversational and SSD='speech'. 

Handling the non- voice PS bearers handover with the target cell as according to Inter/Intra RAT handover 
procedure as defined in TS 23.060 [10]. 

- Initiating the SRVCC handover procedure for handover of the voice component to the target cell via the Sv 
interface and including an emergency indication if this is an emergency session. If there are multiple voice 
bearers and one of those is for IMS emergency session then SGSN shall only execute the SRVCC for 
emergency. 

NOTE: The UE may have 2 voice PS bearers if both emergency and normal IMS voice sessions are ongoing. 
Only the PS voice bearer associated with IMS emergency session will be executed for SRVCC. 

- Coordinating PS handover and SRVCC handover procedures when both procedures are performed. 

- Sending the equipment identifier to the MSC Server during the handover procedure for the case of UEs operating 
in limited service mode. 

- In case of an emergency session, conditionally sending a MAP Subscriber Location Report to a GMLC to 
support location continuity according to TS 23.271 [29]. 

5.3.3A.1 .2 PS bearer splitting function 

The function identifies the voice PS bearer upon HSPA to UTRAN/GERAN SRVCC and performs different handhng 
on this bearer from the non- voice PS bearers (see detailed procedures in subsequent clauses). 

5.3.3A.1 .3 Selection of MSC enhanced for SRVCC 

The MSC enhanced for SRVCC can be selected based on DNS procedures (see TS 29.303 [33]) or local configuration 
in the SGSN. 

5.3.4 UE enhanced for SRVCC 

5.3.4.1 Interworking with 3GPP2 1xGS 

If the UE supports 3GPP2 IxCS access, the IxCS SRVCC UE is a UE that is capable to perform SRVCC to the 3GPP2 
IxCS system. The interaction between UE and E-UTRAN is described in TR 36.938 [7]. The interaction with the 
3GPP2 IxCS system is described in this specification. 

5.3.4.2 Interworking with 3GPP UTRAN/GERAN 

3GPP SRVCC UE is needed to perform SRVCC (see clause 3.1 for 3GPP SRVCC UE definition). The interaction 
between UE and E-UTRAN is described in TS 36.300 [16] and between UE and UTRAN (HSPA) is described in 
TS 25.331 [19]. 

The SRVCC UE indicates to the network that the UE is SRVCC capable when being configured for using IMS speech 
service supported by the home operator, e.g. the IMS Multimedia Telephony Service for bi-directional speech as 
described in TS 22.173 [26] and the operator policy on the SRVCC UE as specified in TS 23.237 [14] does not restrict 
the session transfer. 
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5.3.5 Serving/PDN GW 

No additional requirement due to SRVCC. 

NOTE: If SRVCC is deployed and PCC is not used then the PDN GW is not able to enforce the architecture 
principle to use QCI=1, see clauses 4.1.1 and 4.1.2. 

5.3.6 E-UTRAN 

5.3.6.1 Interworking with 3GPP2 1xCS 

If the E-UTRAN (operator) supports interworking to 3GPP2 IxCS, the E-UTRAN performs the HO trigger, tunnelling 
of the 3GPP2 IxCS signalling messages toward the MME, and interacting with the SRVCC UE as described in 
TR 36.938 [7]. 

E-UTRAN may be capable of determining the neighbour cell list based on the "SRVCC operation possible" indication 
and/or presence of an established QCI=1 bearer for a specific UE. An example algorithm is provided in clause A.l. 

NOTE: If E-UTRAN does not update the neighbour cell list dynamically, if E-UTRAN triggers handover to Ix 
when either the "SRVCC operation possible" indication is set to "false" or there is no established QCI=1 
bearer for a specific UE, this will result in an error case. 

5.3.6.2 Interworking with 3GPP UTRAN/GERAN 

Between UE and E-UTRAN, no additional functionality is required for the E-UTRAN as defined in TS 36.300 [16]. 

When E-UTRAN selects a target cell for SRVCC handover, it needs to send an indication to MME that this handover 
procedure requires SRVCC 

E-UTRAN may be capable of determining the neighbour cell list based on the "SRVCC operation possible" indication 
and/or presence of an established QCI=1 bearer for a specific UE. An example algorithm is provided in clause A.2. 

NOTE: In case E-UTRAN does not update the neighbour cell list dynamically, if E-UTRAN triggers handover to 
a VoIP-incapable cell when the "SRVCC operation possible" indication is set to "false" and there is an 
established voice (QCI=1) bearer for a specific UE, the establishment of the voice bearers will be rejected 
by the target access. 



5.3.6A UTRAN (HSPA) 

When HSPA capable UTRAN selects a target cell for SRVCC handover, it needs to send an indication to SGSN that 
this handover procedure requires SRVCC. 

NOTE 1: UTRAN (HSPA) assumes that SGSN supports SRVCC functionality. 

UTRAN may be capable of determining the neighbour cell list based on the "SRVCC operation possible" indication 
and/or presence of an established voice bearer (i.e. bearer with Traffic Class = Conversational and Source Statistic 
Descriptor = 'speech') for a specific UE. An example algorithm is provided in clause A.3. 

NOTE 2: In case UTRAN does not update the neighbour cell list dynamically, if UTRAN triggers handover to a 
VoIP-incapable cell when the "SRVCC operation possible" indication is set to "false" and there is an 
established bearer with Traffic Class = Conversational and Source Statistic Descriptor = 'speech' for a 
specific UE, the establishment of the voice bearer will be rejected by the target access. 

5.3.7 HSS 

5.3.7.1 Interworking with 3GPP UTRAN/GERAN 

The SRVCC STN-SR, C-MSISDN, and optional ICS flag per VPLMN, for the subscriber are downloaded to MME 
from HSS during E-UTRAN attach procedure. For UTRAN (HSPA), these subscription information are downloaded to 
SGSN from HSS during GPRS attach procedure. HSS also informs the MME/SGSN when STN-SR is modified or 
removed from the subscription. 
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The ICS flag is used by the MSC Server enhanced for SRVCC to behave also as MSC Server enhanced for ICS in 
TS 23.292 [13] if supported by the network. 

NOTE: HSS functionality is not impacted when MSC Server enhanced with SRVCC performs the 
MAP_Update_Location procedure. 

5.3.8 PCC 

The PCRF enforces the architecture principle to use QCI=1 (and traffic-class conversational with source statistics 
descriptor =" speech") for voice bearer with IMS sessions anchored in the SCC AS, based on the service the session 
relates to. This may be achieved by deploying S9 reference point, or configuration and roaming agreements. 

The PCEF should enforce to multiplex the media streams from multiple concurrent normal voice sessions. 

NOTE: In this Release the UE initiated PDF context for voice bearer is not supported. 

5.4 Reference points 

5.4.1 MME-3GPP2 1xCS IWS (S102) 

The S102 reference point provides a tunnel between MME and 3GPP2 IxCS IWS to relay 3GPP2 IxCS signalling 
messages. Ix CS signalling messages are those messages that are defined for A21 interface as described in 3GPP2 
A.S0008-C [8]. 

NOTE. It is up to stage 3 to determine whether the tunnelling protocol for SI 02 can be defined as exactly as in 
A21. If so, SI 02 is then equivalent to A21. 

5.4.2 MME/SGSN - MSC Server (Sv) 

The Sv reference point provides SRVCC support between 3GPP E-UTRAN/UTRAN (HSPA) and 3GPP 
UTRAN/GERAN. 

MME/SGSN includes the optional ICS flag if received from the HSS. 

5.4.3 E-UTRAN - MME (S1 -MME) 

For 3GPP2 IxCS SRVCC, the Sl-MME reference point provides SI Information Transfer message (TR 36.938 [7]) 
between UE and MME to relay the 3GPP2 IxCS signalling messages. 

For 3GPP SRVCC, the Sl-MME reference point allows handover signalling between E-UTRAN and MME. It is 
defined in TS 36.300 [16] 

5.4.3A UTRAN (HSPA) - SGSN (lu-ps) 

For 3GPP HSPA SRVCC, the lu-ps reference point allows handover signalling between UTRAN and SGSN. It is 
defined in TS 25.413 [11]. 

5.4.4 HSS-MME(S6a) 

For 3GPP SRVCC, the S6a is used to download SRVCC related information to MME during E-UTRAN attach 
procedure or to inform MME that STN-SR information in the HSS has changed. 

5.4.5 HSS - SGSN (Or, S6d) 

For 3GPP SRVCC, either the Gr or the S6d is used to download SRVCC related information to SGSN during UTRAN 
(HSPA) attach procedure or to inform SGSN that STN-SR information in the HSS has changed. 
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6 Procedures and flows 

6.1 SRVCC from E-UTRAN to 3GPP2 1xCS 

6.1 .1 E-UTRAN Attach procedure for SRVCC 

E-UTRAN attach or emergency attach procedure for 3GPP2 SRVCC UE is performed as defined in TS 23.401 [2] with 
the following additions: 

- SRVCC UE includes the SRVCC capability indication as part of the "UE Network Capability" in the Attach 
Request message. MME stores this information for SRVCC operation. 

- SRVCC UE capable for IMS emergency calls shall include the SRVCC capability indication as part of the UE 
network capability in the Emergency Attach Request message. MME stores this information for emergency 
SRVCC operation. 

- MME includes a "SRVCC operation possible" indication in the SI AP Initial Context Setup Request, meaning 
that both UE and MME are SRVCC-capable. 

6.1 .2 Service Request procedures for SRVCC 

Service Request procedures for 3GPP2 SRVCC UE are performed as defined in TS 23.401 [2] with the following 
additions: 

- MME includes a "SRVCC operation possible" indication in the SI AP Initial Context Setup Request, meaning 
that both UE and MME are SRVCC-capable. 

6.1 .2A PS Handover procedures for SRVCC 

Intra-E-UTRAN SI -based handover procedures for 3GPP2 SRVCC UE are performed as defined in TS 23.401 [2] with 
the following additions: 

- The target MME includes a "SRVCC operation possible" indication in the Sl-AP Handover Request message, 
meaning that both UE and the target MME are SRVCC-capable. 

For X2-based handover, the source eNodeB includes a "SRVCC operation possible" indication in the X2-AP Handover 
Request message to the target eNodeB as specified in TS 36.423 [32]. 

6.1 .3 Call flows for SRVCC from E-UTRAN 

Figure 6.1.3-1 illustrates a high-level call flow for the E-UTRAN-to-lx voice service continuity procedure. 
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Figure 6.1.3-1: LTE VolP-to-lx CS voice service continuity 

1. Ongoing VoIP session over the IMS access leg established over EPS/E-UTRAN access. 

2. IxCS SRVCC UE sends measurement reports to eNodeB. 

3. The E-UTRAN (e.g., based on some trigger, measurement reports) makes a determination to initiate an 
inter- technology handover to cdma2000 IxRTT. 

4. The E-UTRAN signals the UE to perform an inter-technology handover by sending a Handover from EUTRA 
Preparation Request (3Glx Overhead Parameters, RAND value) message. 

5. The UE initiates signalling for establishment of the CS access leg by sending a UL handover preparation 
Transfer message containing the IxRTT Origination message. For the case of emergency voice service 
continuity, the request includes a Request-Type = "emergency handover" and the MEID (e.g. IMEI) is included. 

6. The E-UTRAN sends an UpHnk SI cdma2000 TunnelHng (MEID, RAND, Ix Origination, Reference CelllD) 
message to the MME. The eNodeB will also include CDMA2000 HO Required Indication IE to Uplink SI 
CDMA2000 Tunnelling message, which indicates to the MME that the handover preparation has started. 

7. Upon reception of the UpHnk SI cdma2000 TunnelHng message, the MME selects a 3GPP2 IxCS IWS as 
specified in clause 5.3.3.1.2 and encapsulates the Ix Origination Message along with the MEID and RAND in a 
S102 Direct Transfer message (as "Ix Air Interface Signalling"). 

8. The traffic channel resources are established in the Ix RTT system and 3GPP2 IxCS procedures for initiation of 
Session Transfer are performed as per 3GPP2 X.S0042 [4]. 

NOTE 1: Step 9 and 3GPP2 IxCS procedures in step 8 are independent of each other. 
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NOTE 2: For non-emergency session transfers, the "VDN" parameter referred to in 3GPP2 X.S0042 [4] 
corresponds to the STN-SR parameter defined in TS 23.237 [14]. 

NOTE 3: The emergency session transfer procedures and procedures for the Ix CS SRVCC UE obtaining the local 
emergency STN-SR will be specified by 3GPP2. 

9. The 3GPP2 IxCS IWS creates a Ix message and encapsulates it in a S102 Direct Transfer message (Ix message, 
Handover indicator). If the 3GPP2 access was able to allocate resources successfully, the Ix message is a Ix 
Handover Direction message and the handover indicator indicates successful resource allocation. Otherwise, the 
handover indicator indicates to the MME that handover preparation failed and the embedded Ix message 
indicates the failure to the UE. 

10. The MME sends the Ix message and CDMA2000 HO Status IE in a DownHnk SI cdma2000 Tunnelling 
message to the E-UTRAN. The CDMA2000 HO Status IE is set according to the handover indicator received 
over the SI 02 tunnel. 

11. If the CDMA2000 HO Status IE indicates successful handover preparation, the E-UTRAN forwards the Ix 
Handoff Direction message embedded in a Mobility from EUTRA Command message to the UE. This is 
perceived by the UE as a Handover Command message. If handover preparation failed, DL Information transfer 
message will be sent instead, with the embedded IxRTT message that indicates the failure to the UE. 

12. Once the UE receives the traffic channel information from the cdma2000 IxRTT system, the UE retunes to the 
IxRTT radio access network and performs traffic channel acquisition with the IxRTT CS access (e.g., IxRTT 
BSS). 

13. The UE sends a IxRTT handoff completion message to the IxRTT CS access (e.g., IxRTT BSS). 

14. The IxRTT CS Access sends message to IxRTT MSC to indicate of handoff done. The resources between Ix CS 
IWS and IxRTT MSC may be released at this step. 

15. Ongoing voice call over the CS access leg established over IxRTT access. The E-UTRAN/EPS context may be 
released based on the normal E-UTRAN/EPS procedure. 

16. The eNodeB sends an SI UE Context Release Request (Cause) message to the MME. Cause indicates the SI 
release procedure is caused by handover from E-UTRAN to IxRTT. 

17. The MME deactivates GBR bearers towards S-GW and P-GW(s) by initiating MME-initiated Dedicated Bearer 
Deactivation procedure as specified in TS 23.401 [2]. The MME starts preservation and suspension of non-GBR 
bearers by sending Suspend Notification message towards S-GW. The S-GW releases Sl-U bearers for the UE 
and sends Suspend Notification message to the P-GW(s). The MME stores in the UE context that the UE is in 
suspended status. All the preserved non-GBR bearers are marked as suspended status in the S-GW and P-GW. 
The P-GW should discard packets if received for the suspended UE. 

18. SI UE Context in the eNodeB is released as specified in TS 23.401 [2]. 

19. For an emergency services session after handover is complete, if the control plane location solution is used on 
the source side, the source MME shall send a Subscriber Location Report carrying an indication of the IxRTT 
MSC (e.g. reference cell ID) to the GMLC associated with the source side as defined in TS 23.271 [29] to 
support location continuity. This enables location continuity for the IxRTT side. Alternatively, if the control 
plane solution is not used on the source side, location continuity procedures shall be instigated on the IxRTT 
side. 

NOTE 4: Location continuity on the IxRTT side will be specified by 3GPP2. 

6.2 E-UTRAN and 3GPP GERAN/UTRAN SRVCC 
6.2.1 E-UTRAN Attach procedure for SRVCC 

E-UTRAN attach procedure for 3GPP SRVCC UE is performed as defined in TS 23.401 [2] with the following 
additions: 
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- SRVCC UE includes the SRVCC capability indication as part of the "MS Network Capability" in the Attach 
Request message and in Tracking Area Updates. MME stores this information for SRVCC operation. The 
procedures are as specified in TS 23.401 [2]. 

NOTE 1 : If the service configuration on the UE is changed (e.g. the user changes between an IMS speech service 
supported by the home operator and a PS speech service incompatible with SRVCC), the UE can change 
its SRVCC capability indication as part of the "MS Network Capability" in a Tracking Area Update 
message. 

- SRVCC UE includes the GERAN MS Classmark 3 (if GERAN access is supported), MS Classmark 2 (if 
GERAN or UTRAN access or both are supported) and Supported Codecs IE (if GERAN or UTRAN access or 
both are supported) in the Attach Request message and in the non-periodic Tracking Area Update messages. 

NOTE 2: MS Classmark 2, MS Classmark 3, STN-SR, C-MSISDN, ICS Indicator and the Supported Codec IE are 
not sent from the source MME to the target MME/SGSN at inter CN-node idle mode mobility. 

- HSS includes SRVCC STN-SR and C MSISDN as part of the subscription data sent to the MME. If the SRVCC 
STN-SR is present, it indicates the UE is SRVCC subscribed. If a roaming subscriber is determined by the 
HPLMN not allowed to have SRVCC in the VPLMN then HSS does not include SRVCC STN-SR and 
C-MSISDN as part of the subscription data sent to the MME. 

- MME includes a "SRVCC operation possible" indication in the SI AP Initial Context Setup Request, meaning 
that both UE and MME are SRVCC-capable. 

E-UTRAN emergency attach procedure for 3GPP SRVCC UE is performed as defined in TS 23.401 [2] and above with 
the following clarifications: 

- SRVCC UE shall include the SRVCC capability indication as part of the "MS Network Capability" in the 
Emergency Attach Request message, and maintained during Tracking Area Updates. MME stores this 
information for SRVCC operation. The procedures are as specified in TS 23.401 [2]. 

6.2.1 A Service Request procedures for SRVCC 

Service Request procedures for 3GPP SRVCC UE are performed as defined in TS 23.401 [2] with the following 
additions: 

- MME includes a "SRVCC operation possible" indication in the SI AP Initial Context Setup Request, meaning 
that both UE and MME are SRVCC-capable. 

6.2.1 B PS Handover procedures for SRVCC 

Intra-E-UTRAN SI -based handover and E-UTRAN to UTRAN (HSPA) lu mode Inter RAT handover procedures for 
3GPP SRVCC UE are performed as defined in TS 23.401 [2] with the following additions: 

- MS Classmark 2, MS Classmark 3, STN-SR, C-MSISDN, ICS Indicator and the Supported Codec IE shall be 
sent from the source MME to the target MME/SGSN if available. 

- The target MME includes a "SRVCC operation possible" indication in the Sl-AP Handover Request message, 
meaning that both UE and the target MME are SRVCC-capable. 

- The target SGSN includes a "SRVCC operation possible" indication in the RANAP Common ID message, 
meaning that both UE and the target SGSN are SRVCC-capable. 

For X2 -based handover, the source eNodeB includes a "SRVCC operation possible" indication in the X2-AP Handover 
Request message to the target eNodeB as specified in TS 36.423 [32]. 

6.2.2 Call flows for SRVCC from E-UTRAN 

NOTE 1: If the MSC Server enhanced for SRVCC controls the target BSS/RNS, the steps depicted with dot-dashed 
arrows representing the MSC-MSC handover procedure defined in TS 23.009 [18] are not executed and 
the functions of the MSC Server enhanced for SRVCC are merged with those of the target MSC. 
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NOTE 2: For the sake of brevity the call flow descriptions use "MSC Server" instead of "MSC Server enhanced for 
SRVCC". 

NOTE 3: The target MSC need not be enhanced for SRVCC. 



6.2.2.1 



SRVCC from E-UTRAN to GERAN without DTM support 



Depicted in figure 6.2.2.1-1 is a call flow for SRVCC from E-UTRAN to GERAN without DTM support. The flow 
requires that eNB can determine that the target is GERAN without DTM support or that the UE is without DTM 
support. 
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Figure 6.2.2.1-1 : SRVCC from E-UTRAN to GERAN without DTM support 

1 . UE sends measurement reports to E-UTRAN. 

2. Based on UE measurement reports the source E-UTRAN decides to trigger an SRVCC handover to GERAN. 

3. Source E-UTRAN sends Handover Required (Target ID, generic Source to Target Transparent Container, 
SRVCC HO Indication) message to the source MME. The E-UTRAN places the "old BSS to new BSS 
information IE" for the CS domain in the generic Source to Target Transparent Container. The SRVCC HO 
indication indicates to the MME that target is only CS capable, hence this is a SRVCC handover operation only 
towards the CS domain. The message includes an indication that the UE is not available for the PS service in the 
target cell. 

4. Based on the QCI associated with the voice bearer (QCI 1) and the SRVCC HO indication, the source MME 
splits the voice bearer from the non voice bearers and initiates the PS-CS handover procedure for the voice 
bearer only towards MSC Server. 
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5. The MME sends a SRVCC PS to CS Request (IMSI, Target ID, STN-SR, C-MSISDN, generic Source to Target 
Transparent Container, MM Context, Emergency Indication) message to the MSC Server. The Emergency 
Indication and the equipment identifier are is included if the ongoing session is emergency session. 
Authenticated IMSI and C-MSISDN shall also be included, if available. The MME received STN-SR and 
C-MSISDN from the HSS as part of the subscription profile downloaded during the E-UTRAN attach procedure. 
The MM Context contains security related information. CS security key is derived by the MME from the 
E-UTRAN/EPS domain key as defined in TS 33.401 [22]. The CS Security key is sent in the MM Context. 

6. The MSC Server interworks the PS-CS handover request with a CS inter-MSC handover request by sending a 
Prepare Handover Request message to the target MSC. The MSC Server assigns a default SAI as Source ID on 
the interface to the target BSS and uses BSSMAP encapsulated for the Prepare Handover Request. 

NOTE 1 : The value of the default SAI is configured in the MSC and allows a release 8 and later BSC to identify 
that the source for the SRVCC Handover is E-UTRAN. To ensure correct statistics in the target BSS the 
default SAI should be different from the S AIs used in UTRAN. 

7. Target MSC performs resource allocation with the target BSS by exchanging Handover Request/ Acknowledge 
messages. 

8. Target MSC sends a Prepare Handover Response message to the MSC Server. 

9. Establishment of circuit connection between the target MSC and the MGW associated with the MSC Server e.g. 
using ISUP lAM and ACM messages. 

10. For non-emergency session, the MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending 
an ISUP lAM (STN-SR) message towards the IMS. For emergency session, the MSC Server initiates the Session 
Transfer by using the locally configured E-STN-SR and by including the equipment identifier. Standard IMS 
Service Continuity or Emergency IMS Service Continuity procedures are applied for execution of the Session 
Transfer, see TS 23.237 [14]. 

NOTE 2: This step can be started after step 8. 

NOTE 3: If the MSC Server is using an ISUP interface, then the initiation of the session transfer for non-emergency 
session may fail if the subscriber profile including CAMEL triggers is not available prior handover (see 
clause 7.3.2.1.3 in TS 23.292 [13]). 

1 1. During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access 
leg. The downlink flow of VoIP packets is switched towards the CS access leg at this point. 

12. Source IMS access leg is released as per TS 23.237 [14]. 
NOTE 4: Steps 1 1 and 12 are independent of step 13. 

13. MSC Server sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the 
source MME. 

14. Source MME sends a Handover Command (Target to Source Transparent Container) message to the source E- 
UTRAN. The message includes information about the voice component only. 

15. Source E-UTRAN sends a Handover from E-UTRAN Command message to the UE. 
16.UEtunestoGERAN. 

17. Handover Detection at the target BSS occurs. The UE sends a Handover Complete message via the target BSS to 
the target MSC. If the target MSC is not the MSC Server, then the Target MSC sends an SES (Handover 
Complete) message to the MSC Server. 

18. The UE starts the Suspend procedure specified in TS 23.060 [10], clause 16.2.1.1.2. The TLLI and RAI pair are 
derived from the GUTI as described in TS 23.003 [27]. This triggers the Target SGSN to send a Suspend 
Notification message to the Source MME. The MME returns a Suspend Acknowledge to the Target SGSN. 

NOTE 5: The MME might not be able to derive the GUTI from the received P-TMSI and RAI pair and therefore it 
might not be able to identify which UE context is associated with the Suspend Notification message. Also 
in this case the bearers are deactivated and/or suspended as in step 22a. 

19. Target BSS sends a Handover Complete message to the target MSC. 
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20. Target MSC sends an SES (Handover Complete) message to the MSC Server. The speech circuit is through 
connected in the MSC Server/MGW according to TS 23.009 [18]. 

21. Completion of the establishment procedure with ISUP Answer message to the MSC Server according to 
TS 23.009 [18]. 

22. MSC Server sends a SRVCC PS to CS Complete Notification message to the source MME, informing it that the 
UE has arrived on the target side. Source MME acknowledges the information by sending a SRVCC PS to CS 
Complete Acknowledge message to the MSC Server. 

22a. The MME deactivates bearers used for voice and other GBR bearers. All GBR bearers are deactivated 

towards S-GW and P-GW by initiating MME-initiated Dedicated Bearer Deactivation procedure as specified in 
TS 23.401 [2]. The MME does not send deactivation request toward the eNodeB on receiving PS-to-CS 
Complete Notification in step 22. PS-to-CS handover indicator is notified to P-GW for voice bearer during the 
bearer deactivation procedure. For GTP-based S5/S8, the S-GW requests the P-GW to delete all GBR bearer 
contexts by sending a Delete Bearer Command message. If dynamic PCC is deployed, the P-GW may interact 
with PCRF as defined in TS 23.203 [31]. For PMIP-based S5/S8, S-GW interacts with the PCRF which in turn 
updates PCC rules for GBR traffic in the P-GW. 

The MME starts preservation and suspension of non-GBR bearers by sending Suspend Notification message 
towards S-GW. For these non-GBR bearers, the S-GW releases Sl-U bearers for the UE and sends Suspend 
Notification message to the P-GW(s). The MME stores in the UE context that UE is in suspended status. All the 
preserved non-GBR bearers are marked as suspended status in the S-GW and P-GW. The P-GW should discard 
packets if received for the suspended UE. 

23a. If the HLR is to be updated, i.e. if the IMSI is authenticated but unknown in the VLR, the MSC Server 

performs a TMSI reallocation towards the UE using its own non-broadcast LAI and, if the MSC Server and other 
MSCA^LRs serve the same (target) LAI, with its own Network Resource Identifier (NRI). 

NOTE 5: The TMSI reallocation is performed by the MSC Server towards the UE via target MSC. 

23b. If the MSC Server performed a TMSI reallocation in step 23a, and if this TMSI reallocation was completed 
successfully, the MSC Server performs a MAP Update Location to the HSS/HLR. 

NOTE 6: This Update Location is not initiated by the UE. 

24. For an emergency services session after handover is complete, the source MME or the MSC Server may send a 
Subscriber Location Report carrying the identity of the MSC Server to a GMLC associated with the source or 
target side, respectively, as defined in TS 23.271 [29] to support location continuity. 

NOTE 7: Any configuration of the choice between a source MME versus MSC Server update to a GMLC needs to 
ensure that a single update occurs from one of these entities when the control plane location solution is 
used on the source and/or target sides. 

After the CS voice call is terminated and if the UE is still in GERAN (or for any other reason specified in TS 24.008), 
then the UE shall resume PS services as specified in TS 23.060 [10]. A Gn SGSN will follow TS 23.060 [10] to resume 
the PDP Context(s). An S4 SGSN will follow TS 23.060 [10] to resume the bearers, and will in addition inform S-GW 
and P-GW(s) to resume the suspended bearers. If the UE has returned to E-UTRAN after the CS voice call was 
terminated, then the UE shall resume PS service by sending TAU to MME. The MME will in addition inform S-GW 
and P-GW(s) to resume the suspended bearers. Resuming the suspended bearers in the S-GW and in the P-GW should 
be done by implicit resume using the Modify Bearer request message if it is triggered by the procedure in operation, e.g. 
RAU, TAU or Service Request. The S-GW is aware of the suspend state of the bearers and will forward the Modify 
Bearer request to the P-GW. Explicit resume using the Resume Notification message should be used in cases when 
Modify Bearer Request is not triggered by the procedure in operation. 

6.2.2.1 A SRVCC from E-UTRAN to GERAN with DTM but without DTM HO support 
and from E-UTRAN to UTRAN without PS HO 

The call flow for this scenario is similar to the call flow depicted in figure 6.2.2.1-1, with the exceptions that the 
Suspend procedure (step 18 and step 22a in figure 6.2.2.1-1) is not performed and that the MME only deactivates 
bearers used for voice (step 22a in figure 6.2.2.1-1) and sets the PS-to-CS handover indicator. The scenario requires that 
eNB can determine that the target is either GERAN with DTM but without DTM HO support and that the UE is 
supporting DTM or that the target is UTRAN (HSPA) without PS HO support. The message in step 3 in figure 6.2.2.1-1 
includes an indication to the MME that the UE is available for PS service in the target cell. Furthermore, if the target is 



ETSI 



3GPP TS 23.216 version 10.5.0 Release 10 



28 



ETSI TS 123 216 VI 0.5.0 (2013-01) 



GERAN, the E-UTRAN places in the generic Source to Target Transparent Container the "old BSS to new BSS 
information IE", while if the target is UTRAN, the generic Source to Target Transparent container is encoded according 
to the Source RNC to Target RNC Transparent Container IE definition. At the end of the procedure described in 
figure 6.2.2.1-1, the remaining PS resources are re-established when the UE performs the Routeing Area update 
procedure. Triggers for performing Routeing Area update procedure are described in TS 23.060 [10]. The target SGSN 
may deactivate the PDP contexts that cannot be established as described in TS 23.060 [10]. 

6.2.2.2 SRVCC from E-UTRAN to UTRAN with PS HO or GERAN with DTM HO 

support 

Depicted in figure 6.2.2.2-1 is a call flow for SRVCC from E-UTRAN to UTRAN or GERAN with DTM HO support, 
including the handling of the non-voice component. The flow requires that eNB can determine that either the target is 
UTRAN with PS HO or the target is GERAN with DTM support and the UE is supporting DTM. 
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Figure 6.2.2.2-1 : SRVCC from E-UTRAN to UTRAN with PS HO or GERAN with DTM HO support 

1 . UE sends measurement reports to E-UTRAN. 

2. Based on UE measurement reports the source E-UTRAN decides to trigger an SRVCC handover to 
UTRAN/GERAN. 

3. If target is UTRAN, the source E-UTRAN sends a Handover Required (Target ID, generic Source to Target 
Transparent Container, SRVCC HO indication) message to the source MME. SRVCC HO indication indicates to 
MME that this is for CS+PS HO. 
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NOTE 1: When the source E-UTRAN indicates using SRVCC HO Indication that target is both CS and PS capable 
and this is a CS+PS HO request, the source MME sends the single received transparent container to both 
the target CS domain and the target PS domain. 

If target is GERAN, the source E UTRAN sends a Handover Required (Target ID, generic Source to Target 
Transparent Container, additional Source to Target Transparent Container, SRVCC HO Indication) message to 
the source MME. The E-UTRAN places the "old BSS to new BSS information IE" for the CS domain in the 
additional Source to Target Transparent Container. The differentiation between CS and PS containers is 
described in TS 36.413 [30]. In this case, the MME identifies from SRVCC HO Indication that this is a request 
for a CS+PS handover. 

4. Based on the QCI associated with the voice bearer (QCI 1) and the SRVCC HO Indication, the source MME 
splits the voice bearer from all other PS bearers and initiates their relocation towards MSC Server and SGSN, 
respectively. 

5a) Source MME initiates the PS-CS handover procedure for the voice bearer by sending a SRVCC PS to CS 
Request (IMSI, Target ID, STN-SR, C-MSISDN, Source to Target Transparent Container, MM Context, 
Emergency Indication) message to the MSC Server. The Emergency Indication and the equipment identifier are 
included if the ongoing session is emergency session. Authenticated IMSI and C-MSISDN shall also be included 
if available. The message includes information relevant to the CS domain only. MME received STN-SR and 
C-MSISDN from the HSS as part of the subscription profile downloaded during the E-UTRAN attach procedure. 
MM Context contains security related information. CS security key is derived by the MME from the 
E-UTRAN/EPS domain key as defined in TS 33.401 [22]. The CS Security key is sent in the MM Context. 

5b) MSC Server interworks the PS-CS handover request with a CS inter-MSC handover request by sending a 

Prepare Handover Request message to the target MSC. If the target system is GERAN, the MSC Server assigns a 
default SAI as Source ID on the interface to the target BSS and uses BSSMAP encapsulated for the Prepare 
Handover Request. If the target system is UTRAN, the MSC Server uses RANAP encapsulated for the Prepare 
Handover Request. 

NOTE 2: The value of the default SAI is configured in the MSC and allows a release 8 and later BSC to identify 
that the source for the SRVCC Handover is E-UTRAN. To ensure correct statistics in the target BSS the default 
SAI should be different from the S AIs used in UTRAN. 

5c) Target MSC requests resource allocation for the CS relocation by sending the Relocation Request/Handover 
Request message to the target RNS/BSS. If the target RAT is UTRAN, Relocation Request/Handover Request 
message contains the generic Source to Target Transparent Container. If the target RAT is GERAN, Relocation 
Request/Handover Request message contains the additional Source to Target Transparent Container. 

6. In parallel to the previous step the source MME initiates relocation of the PS bearers. The following steps are 
performed (for details see TS 23.401 [2] clauses 5.5.2.1 and 5.5.2.3): 

a) Source MME sends a Forward Relocation Request (generic Source to Target Transparent Container, MM 
Context, PDN Connections IE) message to the target SGSN. If the target SGSN uses S4 based interaction 
with S-GW and P-GW, the PDN Connections IE includes bearer information for all bearers except the voice 
bearer. The handling of security keys for PS handover of the remaining non- voice PS bearers is specified in 
TS 33.401 [22]. 

NOTE 3: If the target SGSN uses Gn/Gp based interaction with GGSN the Forward Relocation Request will 
contain PDP Contexts, instead of PDN Connections IE, including bearer information for all bearers 
except the voice bearer. 

b) Target SGSN requests resource allocation for the PS relocation by sending the Relocation Request/Handover 
Request (Source to Target Transparent Container) message to the target RNS/BSS. 

7. After the target RNS/BSS receives both the CS relocation/handover request with the PS relocation/handover 
request, it assigns the appropriate CS and PS resources. The following steps are performed: 

a) Target RNS/BSS acknowledges the prepared PS relocation/handover by sending the Relocation Request 
Acknowledge/Handover Request Acknowledge (Target to Source Transparent Container) message to the 
target SGSN. 

b) Target SGSN sends a Forward Relocation Response (Target to Source Transparent Container) message to the 
source MME. 
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8. In parallel to the previous step the following steps are performed: 

a) Target RNS/BSS acknowledges the prepared CS relocation/handover by sending the Relocation Request 
Acknowledge/Handover Request Acknowledge (Target to Source Transparent Container) message to the 
target MSC. 

b) Target MSC sends a Prepare Handover Response (Target to Source Transparent Container) message to the 
MSC Server. 

c) Establishment of circuit connection between the target MSC and the MGW associated with the MSC Server 
e.g. using ISUP lAM and ACM messages. 

NOTE 4: The Target to Source Transparent Container sent to the target SGSN is step 7a and the Target to Source 
Transparent Container sent to the target MSC in step 8a, include the same allocation of CS and PS 
resources (e.g. the target BSS includes the same DTM Handover Command in both containers). 

9. For non-emergency session, the MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending 
an ISUP lAM (STN-SR) message towards the IMS. For emergency session, the MSC Server initiates the Session 
Transfer by using the locally configured E-STN-SR and by including the equipment identifier. Standard IMS 
Service Continuity or Emergency IMS Service Continuity procedures are applied for execution of the Session 
Transfer, TS 23.237 [14]. 

NOTE 5: This step can be started after step 8b. 

NOTE 6: If the MSC Server is using an ISUP interface, then the initiation of the session transfer for non-emergency 
sessions may fail if the subscriber profile including CAMEL triggers is not available prior handover (see 
clause 7.3.2.1.3 of TS 23.292 [13]). 

10. During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access 
leg according to TS 23.237 [14]. The downlink flow of VoIP packets is switched towards the CS access leg at 
this point. 

11. The source IMS access leg is released according to TS 23.237 [14]. 
NOTE 7: Steps 10 and 1 1 are independent of step 12. 

12. The MSC Server sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the 
source MME. 

13. Source MME synchronises the two prepared relocations and sends a Handover Command (Target to Source 
Transparent Container) message to the source E-UTRAN. 

NOTE 8: When the target cell is GERAN, the MME may receive different Target to Source Transparent Containers 
from the MSC Server and from the SGSN, i.e. a "New BSS to Old BSS Information" (see 
TS 48.008 [23]) may be received from the MSC Server and a "Target BSS to Source BSS Transparent 
Container" (see TS 48.018 [24]) may be received from the SGSN. 

14. E-UTRAN sends a Handover from E-UTRAN Command message to the UE. 

15. UE tunes to the target UTRAN/GERAN cell. 

16. Handover Detection at the target RNS/BSS occurs. The UE sends a Handover Complete message via the target 
RNS/BSS to the target MSC. If the target MSC is not the MSC Server, then the Target MSC sends an SES 
(Handover Complete) message to the MSC Server. At this stage, the UE re-establishes the connection with the 
network and can send/receive voice data. 

17. The CS relocation/handover is complete. The following steps are performed: 

a) Target RNS/BSS sends Relocation Complete/Handover Complete message to the target MSC. 

b) Target MSC sends an SES (Handover Complete) message to the MSC Server. The speech circuit is through 
connected in the MSC Server/MGW according to TS 23.009 [18]. 

c) Completion of the establishment procedure with ISUP Answer message to the MSC Server according to 
TS 23.009 [18]. 
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d) MSC Server sends a SRVCC PS to CS Complete Notification message to the source MME. Source MME 
acknowledges the information by sending a SRVCC PS to CS Complete Acknowledge message to the MSC 
Server. 

e) The source MME deactivates the voice bearer towards S-GW/P-GW and sets the PS-to-CS handover 
indicator to Delete Bearer Command message. This triggers MME-initiated Dedicated Bearer Deactivation 
procedure as specified in TS 23.401 [2]. The MME does not send deactivation request toward the eNodeB on 
receiving PS-to-CS Complete Notification in step 17d. If dynamic PCC is deployed, the PGW may interact 
with PCRF as defined in TS 23.203 [31]. 

f) If the HLR is to be updated, i.e. if the IMSI is authenticated but unknown in the VLR, the MSC Server 
performs a TMSI reallocation towards the UE using its own non-broadcast LAI and, if the MSC Server and 
other MSCA^LRs serve the same (target) LAI, with its own Network Resource Identifier (NRI). 

NOTE 9: The TMSI reallocation is performed by the MSC Server towards the UE via target MSC. 

g) If the MSC Server performed a TMSI reallocation in step 17f, and if this TMSI reallocation was completed 
successfully, the MSC Server performs a MAP Update Location to the HSS/HLR. 

NOTE 10: This Update Location is not initiated by the UE. 

18. In parallel to the previous step, the PS relocation/handover is completed. The following steps are performed: 

a) Target RNS/BSS sends Relocation Complete/Handover Complete message to target SGSN. 

b) Target SGSN sends a Forward Relocation Complete message to the source MME. After having completed 
step 17e, the source MME acknowledges the information by sending a Forward Relocation Complete 
Acknowledge message to the target SGSN. 

c) Target SGSN updates the bearer with S-GW/P-GW/GGSN as specified in TS 23.401 [2]. 

d) The MME sends Delete Session Request to the SGW as defined in TS 23.401 [2]. 

e) The source MME sends a Release Resources message to the Source eNodeB as defined in TS 23.401 [2]. The 
Source eNodeB releases its resources related to the UE. 

NOTE ILRouting Area Update procedures by the UE are done in accordance with TS 23.401 [2]. 

19. For an emergency services session after handover is complete, the source MME or the MSC Server may send a 
Subscriber Location Report carrying the identity of the MSC Server to a GMLC associated with the source or 
target side, respectively, as defined in TS 23.271 [29] to support location continuity. 

NOTE 12: Any configuration of the choice between a source MME versus MSC Server update to a GMLC needs to 
ensure that a single update occurs from one of these entities when the control plane location solution is 
used on the source and/or target sides. 

In case the MME determines that only the relocation of the voice bearer but not the relocation of one or more PS 
bearers succeeds, then the MME proceeds with step 13 after receiving SRVCC PS to CS Response from the MSC 
Server in step 12 and both UE and MME continue the procedure as described in clause 6.2.2.1 A. 

6.3 UTRAN (HSPA) and 3GPP GERAN/UTRAN SRVCC 
6.3.1 GPRS Attach procedure for SRVCC 

GPRS attach procedure for 3GPP SRVCC UE is performed as defined in TS 23.060 [10] with the following additions: 

- SRVCC UE includes the SRVCC capability indication as part of the "MS Network Capability" in the Attach 
Request message and in Routeing Area Updates. SGSN stores this information for SRVCC operation. 

NOTE 1 : If the service configuration on the UE is changed (e.g. the user changes between an IMS speech service 
supported by the home operator and a PS speech service incompatible with SRVCC), the UE can change 
its SRVCC capability indication as part of the "MS Network Capability" in a Routeing Area Update 
message. 
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- SRVCC UE includes the GERAN MS Classmark 3 (if GERAN access is supported), MS Classmark 2 and 
Supported Codecs IE in the Attach Request message and in the non-periodic Routeing Area Update messages. 

NOTE 2: MS Classmark 2, MS Classmark 3, STN-SR, C-MSISDN, ICS Indicator and the Supported Codec IE are 
not sent from the source SGSN to the target MME/SGSN at inter CN-node idle mode mobility. 

- HSS includes SRVCC STN-SR and C MSISDN as part of the subscription data sent to the SGSN. If the SRVCC 
STN-SR is present, it indicates the UE is SRVCC subscribed. If a roaming subscriber is determined by the 
HPLMN not allowed to have SRVCC in the VPLMN then HSS does not include STN-SR and C-MSISDN as 
part of the subscription data sent to the SGSN. 

- SGSN includes a "SRVCC operation possible" indication in the RANAP Common ID message, meaning that 
both UE and SGSN are SRVCC-capable. 

GPRS emergency attach procedure for 3GPP SRVCC UE is performed as defined in TS 23.060 [10] and above with the 
following clarifications: 

- SRVCC UE shall include the SRVCC capability indication as part of the "MS Network Capability" in the 
Emergency Attach Request message and maintained during Routeing Area Updates. SGSN stores this 
information for SRVCC operation. 

6.3.1 A Service Request procedures for SRVCC 

Service Request procedures for 3GPP SRVCC UE are performed as defined in TS 23.060 [10] with the following 
additions: 

- SGSN includes a "SRVCC operation possible" indication in the RANAP Common ID message, meaning that 
both UE and SGSN are SRVCC-capable. 

6.3.1 B PS Handover procedures for SRVCC 

Intra-UTRAN (HSPA) SRNS Relocation procedure for 3GPP SRVCC UE are performed as defined in TS 23.060 [10] 
and UTRAN (HSPA) lu mode to E-UTRAN Inter RAT handover are performed as defined in TS 23.401 [2], with the 
following additions: 

- MS Classmark 2, MS Classmark 3, STN-SR, C-MSISDN, ICS Indicator and the Supported Codec IE shall be 
sent from the source SGSN to the target SGSN/MME if available. 

- The target SGSN includes a "SRVCC operation possible" indication in the RANAP Common ID message, 
meaning that both UE and the target SGSN are SRVCC-capable. 

- The target MME includes a "SRVCC operation possible" indication in the Sl-AP Handover Request message, 
meaning that both UE and the target MME are SRVCC-capable. 

6.3.2 Call flows for SRVCC from UTRAN (HSPA) 

NOTE 1: If the MSC Server enhanced for SRVCC controls the target BSS/RNS, the steps depicted with dot-dashed 
arrows representing the MSC-MSC handover procedure defined in TS 23.009 [18] are not executed and 
the functions of the MSC Server enhanced for SRVCC are merged with those of the target MSC. 

NOTE 2: For the sake of brevity the call flow descriptions use "MSC Server" instead of "MSC Server enhanced for 
SRVCC". 

NOTE 3: The target MSC need not be enhanced for SRVCC. 

6.3.2.1 SRVCC from UTRAN (HSPA) to GERAN without DTM support 

Depicted in figure 6.3.2.1-1 is a call flow for SRVCC from HSPA to GERAN without DTM support. The flow requires 
that NB can determine that the target is GERAN without DTM support or that the UE is without DTM support. 
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Figure 6.3.2.1-1 : SRVCC from UTRAN (HSPA) to GERAN without DTM support 

1. UE sends measurement reports to Source UTRAN (HSPA). 

2. Based on UE measurement reports the source UTRAN (HPSA) decides to trigger a handover to GERAN. 

3. Source UTRAN (HSPA) sends Relocation Required (Target ID, Source to Target Transparent Container, 
SRVCC Handover Indication) message to the source SGSN. The UTRAN (HSPA) includes the "old BSS to new 
BSS information IE" for the CS domain. The SRVCC Handover Indication indicates to the SGSN that this is a 
SRVCC handover operation only towards the CS domain. The message includes an indication that the UE is not 
available for PS service in the target cell. 

4. Based on the Traffic Class associated with conversational and Source Statistic Descriptor = speech, and the 
SRVCC Handover Indication the source SGSN splits the voice bearer from the non- voice bearers and initiates 
the PS-CS handover procedure for the voice bearer only towards MSC server. 

5. Source SGSN sends a SRVCC PS to CS Request (IMSI, Target ID, STN-SR, C-MSISDN, Source to Target 
Transparent Container, MM Context, Emergency Indication, Source SAI) message to the MSC Server. The 
Emergency Indication and the equipment identifier are included if an ongoing session is an emergency session. 
Authenticated IMSI and C-MSISDN shall also be included if available. SGSN received the STN-SR and 
C-MSISDN from the HSS as part of the subscription profile downloaded during the UTRAN (HSPA) attach 
procedure. The MM Context contains security related information. The CS Security key is derived by SGSN 
from the UTRAN (HSPA)/EPS domain key as defined in TS 33.102 [25]. The Source SAI shall be set to the 
Serving Area Identifier received from the source RNC. 

6. The MSC Server interworks the PS handover request with a CS inter-MSC handover request by sending a 
Prepare Handover Request message to the target MSC. The MSC Server uses BSSMAP encapsulated for the 
Prepare Handover Request. 
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7. Target MSC performs resource allocation with the target BSS by exchanging Handover Request/ Acknowledge 
messages. 

8. Target MSC sends a Prepare Handover Response message to the MSC Server. 

9. Establishment of circuit connection between the target MSC and the MGW associated with the MSC Server e.g. 
using ISUP lAM and ACM messages. 

10. For non-emergency session, the MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending 
an ISUP lAM (STN-SR) message towards the IMS. For emergency session, the MSC Server initiates the Session 
Transfer by using the locally configured E-STN-SR and by including the equipment identifier. Standard IMS 
Service Continuity or Emergency IMS Service Continuity procedures are applied for execution of the Session 
Transfer, see TS 23.237 [14]. 

NOTE 1: This step can be started after step 8. 

NOTE 2: If the MSC Server is using an ISUP interface, then the initiation of the session transfer for non-emergency 
session may fail if the subscriber profile including CAMEL triggers is not available prior handover (see 
clause 7.3.2.1.3 of TS 23.292 [13]). 

1 1. During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access 
leg. The downlink flow of VoIP packets is switched towards the CS access leg at this point. 

12. Source IMS access leg is released according to TS 23.237 [14]. 
NOTE 3: Steps 1 1 and 12 are independent of step 13. 

13. MSC Server sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the 
source SGSN. 

14. Source SGSN sends a Relocation Command (Target to Source Transparent Container) message to the source 
UTRAN (HSPA). The message includes information about the voice component only. 

15. Source UTRAN (HSPA) sends a Handover Command message to the UE. 
16.UEtunestoGERAN. 

17. Handover Detection at the target BSS occurs. The UE sends a Handover Complete message via the target 
RNS/BSS to the target MSC. 

18. The UE starts the Suspend procedure specified in TS 23.060 [10], clause 16.2.1.1.2. The TLLI and RAI pair are 
derived from the GUTI as described in TS 23.003 [27]. This triggers the Target SGSN to send a Suspend 
Request (Gn/Gp SGSN) or Suspend Notification (S4 SGSN) message to the Source SGSN. The Source SGSN 
returns a Suspend Response or Suspend Acknowledge message to the Target SGSN. 

19. Target BSS sends a Handover Complete message to the target MSC. 

20. Target MSC sends an SES (Handover Complete) message to the MSC Server. The speech circuit is through 
connected in the MSC Server/MGW according to TS 23.009 [18]. 

21. Completion of the establishment procedure with ISUP Answer message to the MSC Server according to 
TS 23.009 [18]. 

22. MSC Server sends a SRVCC PS to CS Complete Notification message to the source SGSN, informing it that the 
UE has arrived on the target side. Source SGSN acknowledges the information by sending a SRVCC PS to CS 
Complete Acknowledge message to the MSC Server. 

22a. After the SGSN received a Suspend Request/Notification in step 18, the SGSN behaves as follows: 

If the SGSN uses Gn/Gp based interaction with GGSN, then: 

- The SGSN deactivates PDP Contexts used for voice and it suspends PDP Contexts using background or 
interactive class. 

For a PDP Context using streaming or conversational traffic class not used for voice, the PDP Context is 
preserved and the maximum bitrate is downgraded to Kbit/s. 
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If the SGSN uses S4 based interaction with S-GW and P-GW, then: 

- The SGSN deactivates bearers used for voice and other GBR bearers towards S-GW and P-GW by initiating 
MS-and SGSN Initiated Bearer Deactivation procedure as specified in TS 23.060 [10]. PS-to-CS handover 
indicator is notified to P-GW for voice bearer during the bearer deactivation procedure. 

- If dynamic PCC is deployed, the P-GW may interact with PCRF as defined in TS 23.203 [31]. 

- The SGSN starts preservation and suspension of non-GBR bearers by sending Suspend Notification message 
towards S-GW. The S-GW releases all RNC related information (address and TEIDs) for the UE if Direct 
Tunnel is established, and sends Suspend Notification message to the P-GW(s). 

The SGSN stores in the UE context that UE is in suspended status. All the preserved non-GBR bearers are 
marked as suspended status in the S-GW and P-GW. The P-GW should discard packets if received for the 
suspended UE. 

23a. If the HLR is to be updated, i.e. if the IMSI is authenticated but unknown in the VLR, the MSC Server 

performs a TMSI reallocation towards the UE using its own non-broadcast LAI and, if the MSC Server and other 
MSCA^LRs serve the same (target) LAI, with its own Network Resource Identifier (NRI). 

NOTE 4: The TMSI reallocation is performed by the MSC Server towards the UE via target MSC. 

23b. If the MSC Server performed a TMSI reallocation in step 23a, and if this TMSI reallocation was completed 
successfully, the MSC Server performs a MAP Update Location to the HSS/HLR. 

NOTE 5: This Update Location is not initiated by the UE. 

24. For an emergency services session after handover is complete, the source SGSN or the MSC Server may send a 
Subscriber Location Report carrying the identity of the MSC Server to a GMLC associated with the source or 
target side, respectively, as defined in TS 23.271 [29] to support location continuity. 

NOTE 6: Any configuration of the choice between a source SGSN versus MSC Server update to a GMLC needs to 
ensure that a single update occurs from one of these entities when the control plane location solution is 
used on the source and/or target sides. 

After the CS voice call is terminated and if the UE is still in GERAN or UTRAN (or for any other reason according to 
TS 24.008), then the UE shall resume PS services (as specified in TS 23.060 [10]). A Gn/Gp SGSN will follow 
TS 23.060 [10] to resume the PDP Context(s). An S4 SGSN will also follow TS 23.060 [10] to resume the bearers, and 
will in addition inform S-GW and P-GW(s) to resume the suspended bearers. Resuming the suspended bearers in the S- 
GW and in the P-GW should be done by implicit resume using the Modify Bearer request message if it is triggered by 
the procedure in operation, e.g. RAU, TAU or Service Request. The S-GW is aware of the suspend state of the bearers 
and will forward the Modify Bearer request to the P-GW. Explicit resume using the Resume Notification message 
should be used in cases when Modify Bearer Request is not triggered by the procedure in operation. 

6.3.2.1 A SRVCC from UTRAN (HSPA) to GERAN with DTM but without DTIVI HO 

support and from UTRAN (HSPA) to UTRAN without PS HO 

The call flow for this scenario is similar to the call flow depicted in figure 6.3.2.1-1, with the exceptions that the 
Suspend procedure (step 18 and step 22a in figure 6.3.2.1-1) is not performed and that the source SGSN only 
deactivates bearers used for voice and sets the PS-to-CS handover indicator. The scenario requires that NB can 
determine that the target is either GERAN with DTM but without DTM HO support and that the UE is supporting DTM 
or that the target is UTRAN (HSPA) without PS HO support. The message in step 3 in figure 6.3.2.1 1 includes an 
indication to the SGSN that the UE is available for PS service in the target cell. At the end of the procedure described in 
figure 6.3.2.1-1, the remaining PS resources are re-established when the UE performs the Routeing Area update 
procedure. Triggers for performing Routeing Area update procedure are described in TS 23.060 [10]. The target SGSN 
may deactivate the PDP contexts that cannot be established as described in TS 23.060 [10]. 

6.3.2.2 SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO support 

Depicted in figure 6.3.2.2-1 is a call flow for SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO 
support, including the handling of the non voice component. 
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Figure 6.3.2.2-1 : SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO support 

1. UE sends measurement reports to Source UTRAN (HSPA). 

2. Based on UE measurement reports the source UTRAN (HSPA) decides to trigger a handover to 
UTRAN/GERAN. 

2a. In case of SRVCC to UTRAN the RNC shall initiate the SRVCC Preparation procedure by sending an SRVCC 
CS KEYS REQUEST message to the source SGSN. 

2b. The SGSN shall respond to the RNC with SRVCC CS KEYS RESPONSE message containing the Integrity 
Protection Key IE, the Encryption Key IE and the SRVCC Information IE. 

3. If target is UTRAN, the source UTRAN (HSPA) sends a Relocation Required (Target ID, Source RNC to Target 
RNC Transparent Container, SRVCC Handover Indication) message to the source SGSN. UTRAN (HSPA) also 
indicates to SGSN that this is for CS+PS HO. 

NOTE 1: When the source UTRAN (HSPA) indicates that this is a CS+PS HO request, the source SGSN sends the 
single received transparent container to both the target CS domain and the target PS domain. 

If target is GERAN, the source UTRAN (HSPA) sends a Relocation Required (Target ID, Old BSS to New ESS 
Information IE for the CS domain and Source BSS to Target BSS Transparent Container for the PS Domain, 
SRVCC Handover Indication) message to the source SGSN. The differentiation between CS and PS containers is 
described in TS 25.413 [1 1]. In this case, the SGSN identifies from the SRVCC Handover Indication that this is 
a request for a CS+PS handover. 
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4. Based on the Traffic Class associated with conversational and Source Statistic Descriptor = speech, and the 
SRVCC Handover Indication the Source SGSN splits the voice bearer from all other PS bearers and initiates 
their relocation towards MSC Server and SGSN, respectively. 

5a) Source SGSN initiates the PS-CS handover procedure for the voice bearer by sending a SRVCC PS to CS 
Request (IMSI, Target ID, STN-SR, C-MSISDN, Source to Target Transparent Container, MM Context, 
Emergency Indication, Source SAI) message to the MSC Server. The Emergency Indication and the equipment 
identifier are included if the ongoing session is emergency session. Authenticated IMSI and C-MSISDN shall be 
included if available. The message includes information relevant to the CS domain only. SGSN received STN- 
SR and C-MSISDN from the HSS as part of the subscription profile downloaded during the UTRAN (HSPA) 
attach procedure. MM Context contains security related information. The CS Security key is derived by the 
SGSN from the UTRAN (HSPA)/EPS domain key as defined in TS 33.102 [25]. If the target system is GERAN, 
the Source SAI shall be set to the Serving Area Identifier received from the source RNC. 

5b) MSC Server interworks the PS handover request with a CS inter-MSC handover request by sending a Prepare 
Handover Request message to the target MSC. If the target system is GERAN, MSC Server uses BSSMAP 
encapsulated for the Prepare Handover Request. If the target system is UTRAN, MSC Server uses RANAP 
encapsulated for the Prepare Handover Request. 

5c) Target MSC requests resource allocation for the CS relocation by sending the Relocation Request/Handover 
Request (Source to Target Transparent Container) message to the target RNS/BSS. 

6. In parallel to the previous step the source SGSN initiates relocation of the PS bearers. The following steps are 
performed (for details see TS 23.060 [10]): 

a) If the target SGSN uses S4 based interaction with S-GW and P-GW, the source SGSN sends a Forward 
Relocation Request (Source to Target Transparent Container, MM Context, PDP Context) message to the 
target SGSN. The PDP Context includes bearer information for all bearers except the voice bearer. The 
handling of security keys for PS handover of the remaining non-voice PS bearers is specified in 

TS 33.401 [22]. 

If the target SGSN uses Gn/Gp based interaction with GGSN, the Source SGSN sends a Forward Relocation 
Request (Source to Target Transparent Container, MM Context and PDP Context) message to the target 
SGSN. The PDP Context includes bearer information for all bearers except the voice bearer. The handling of 
security keys for PS handover of the remaining non- voice PS bearers is specified in TS 33.102 [25]. 

b) Target SGSN requests resource allocation for the PS relocation by sending the Relocation Request/Handover 
Request (Source to Target Transparent Container) message to the target RNS/BSS. 

7. Target RNS/BSS coordinates the CS relocation request with the PS relocation request and assigns resources. The 
following steps are performed: 

a) Target RNS/BSS acknowledges the prepared PS relocation by sending the Relocation Request 
Acknowledge/Handover Request Acknowledge (Target to Source Transparent Container) message to the 
target SGSN. 

b) Target SGSN sends a Forward Relocation Response (Target to Source Transparent Container) message to the 
source SGSN. 

8. In parallel to the previous step the following steps are performed: 

a) Target RNS/BSS acknowledges the prepared CS relocation by sending the Relocation Request 
Acknowledge/Handover Request Aclmowledge (Target to Source Transparent Container) message to the 
target MSC. 

b) Target MSC sends a Prepare Handover Response (Target to Source Transparent Container) message to the 
MSC Server. 

c) Establishment of circuit connection between the target MSC and the MGW associated with the MSC Server 
e.g. using ISUP lAM and ACM messages. 

9. For non-emergency session, the MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending 
an ISUP lAM (STN-SR) message towards the IMS. For emergency session, the MSC Server initiates the Session 
Transfer by using the locally-configured E-STN-SR and by including the equipment identifier. Standard IMS 
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Service Continuity or Emergency IMS Service Continuity procedures are applied for execution of the Session 
Transfer, see TS 23.237 [14]. 

NOTE 2: This step can be started after step 8b. 

NOTE 3: If the MSC Server is using an ISUP interface, then the initiation of the session transfer for non-emergency 
sessions may fail if the subscriber profile including CAMEL triggers is not available prior handover (see 
clause 7.3.2.1.3 of TS 23.292 [13]). 

10. During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access 
leg according to TS 23.237 [14]. The downlink flow of VoIP packets is switched towards the CS access leg at 
this point. 

11. The source IMS access leg is released according to TS 23.237 [14]. 
NOTE 4: Steps 10 and 1 1 are independent of step 12. 

12. The MSC Server sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the 
source SGSN. 

13. Source SGSN synchronises the two prepared relocations and sends a Relocation Command (Target to Source 
Transparent Container) message to the source UTRAN (HSPA). If the target is GERAN, the source RNC shall 
receive the SRVCC Information IE containing the NONCE IE. 

14. UE tunes to the target UTRAN/GERAN cell. 

15. UTRAN (HSPA) sends a Handover Command message to the UE. 

16. Handover Detection at the target RNS/BSS. The UE sends a Handover Complete message via the target 
RNS/BSS to the target MSC. 

17. The CS relocation is complete. The following steps are performed: 

a) Target RNS/BSS sends Relocation Complete/Handover Complete message to the target MSC. 

b) Target MSC sends an SES (Handover Complete) message to the MSC Server. The speech circuit is through 
connected in the MSC Server/MGW according to TS 23.009 [18]. 

c) Completion of the establishment procedure with ISUP Answer message to the MSC Server according to 
TS 23.009 [18]. 

d) MSC Server sends a SRVCC PS to CS Complete Notification message to the source SGSN. Source SGSN 
acknowledges the information by sending a SRVCC PS to CS Complete Acknowledge message to the MSC 
Server. 

e) The source SGSN deletes the voice bearer towards GGSN/S-GW/P-GW and sets the PS-to-CS handover 
indicator. If dynamic PCC is deployed, the PGW may interact with PCRF as defined in TS 23.203 [31]. 

f) If the HLR is to be updated, i.e. if the IMSI is authenticated but unknown in the VLR, the MSC Server 
performs a TMSI reallocation towards the UE using its own non-broadcast LAI and, if the MSC Server and 
other MSCA^LRs serve the same (target) LAI, with its own Network Resource Identifier (NRI). 

NOTE 5: The TMSI reallocation is performed by the MSC Server towards the UE via target MSC. 

g) If the MSC Server performed a TMSI reallocation in step 17f, and if this TMSI reallocation was completed 
successfully, the MSC Server performs a MAP Update Location to the HSS/HLR. 

NOTE 6: this Update Location is not initiated by the UE. 

18. In parallel to the previous step, the PS relocation is complete. The following steps are performed: 

a) Target RNS/BSS sends Relocation Complete/Handover Complete message to target SGSN. 

b) Target SGSN sends a Forward Relocation Complete message to the source SGSN. After having completed 
step 17e, source SGSN acknowledges the information by sending a Forward Relocation Complete 
Acknowledge message to the target SGSN. 
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c) Target SGSN updates the bearer with GGSN/S-GW/P-GW. 

d) The Source S4-SGSN sends delete Session Request to the SGW as defined in TS 23.401 [2]. 

19. For an emergency services session after handover is complete, the source SGSN or the MSC Server may send a 
Subscriber Location Report carrying the identity of the MSC Server to a GMLC associated with the source or 
target side, respectively, as defined in TS 23.271 [29] to support location continuity. 

NOTE 7: Any configuration of the choice between a source SGSN versus MSC Server update to a GMLC needs to 
ensure that a single update occurs from one of these entities when the control plane location solution is 
used on the source and/or target sides. 

In case the SGSN determines that only the relocation of the voice bearer but not the relocation of one or more PS 
bearers succeeds, then the SGSN proceeds step 13 after receiving SRVCC PS to CS Response from the MSC Server in 
step 12 and both UE and SGSN continue the procedure described in clause 6.3.2.1 A. 



7 Charging 

See TS 23.292 [13] clause 8 on charging for guidance on the handling of charging for SRVCC. 



8 Handover Failure 

8.1 Failure in EUTRAN/UTRAN (HSPA) and 3GPP 
UTRAN/GERAN SR-VOC 

8.1 .1 Failure before MSC Server initiates Session Transfer 

If a failure is encountered before the MSC Server initiates Session Transfer, then the standardised handover failure 
procedures apply according to TS 23.401 [2]. No further action is required by the UE. 

8.1 .la Failure after MSC Server initiates Session Transfer 
8.1 .1 a.1 Failure before responding to PS to CS HO request 

If the MSC Server receives a negative response from IMS during the Session Transfer procedure (e.g., due to invalid 
STN-SR, or temporary failure, etc) and the MSC Server has not yet responded back to MME/SGSN with a positive PS 
to CS Response message due to successful target CS radio resource reservation, then MSC Server shall reject this PS To 
CS Request with a Reject cause pointing to either permanent or temporary "Session Transfer leg establishment error" 
and MSC Server shall release the CS radio resource at the target RAT. 

NOTE 1: An example of permanent error can be an invalid STN-SR (i.e., IMS returns with "404 user unknown"). 

When MME/SGSN receives the PS to CS Response with a reject cause related to "permanent Session Transfer leg 
establishment error", MME/SGSN may take that indication into account to prevent further SRVCC handover attempts. 

NOTE 2: It is an implementation option on when the MME/SGSN may retry SRVCC after receiving a "permanent 
Session Transfer leg establishment error" . 

The following figure 8. 1.1 a- 1 shows the overall procedure when the MSC Server aware of the Session Transfer failure 
prior to responding to PS to CS HO request. 
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Figure 8.1.1a-1 : SRVCC Handover Rejection due to Session Transfer leg establishment error before 

responding to PS to CS HO request 

8.1 .1 a.2 Failure after responding to PS to CS HO request 

If the MSC Server receives a negative response from IMS during the initiates Session Transfer procedure (e.g. due to 
invalid STN-SR, or temporary failure, etc) and the MSC Server has already responded back to MME/SGSN with a 
positive PS to CS Response message due to successful target CS radio resource reservation and has not yet sent PS to 
CS Complete Notification, then MSC Server shall indicate to MME/SGSN with an error cause pointing to either 
permanent or temporary "Session Transfer leg establishment error" in PS to CS complete notification message. 
MME/SGSN shall perform the bearer release procedure as according to the normal SRVCC procedure as defined in 
clauses 6.2 and 6.3. 

NOTE: MSC Server may wait for the status of Session Transfer procedure before sending the CS Complete 
Notification to MME/SGSN. 

When MME/SGSN receives this PS to CS Complete notification message with an error cause pointing to "permanent 
Session Transfer leg establishment error", MME/SGSN may take that indication into account to prevent further SRVCC 
handover attempts. 

The following figure 8.1.1a-2 shows the overall procedure when the MSC Server aware of the Session Transfer failure 
after the PS to CS HO request has been responded to MME/SGSN. 
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Figure 8.1.1a-1 : SRVCC Handover Rejection due to Session Transfer leg establishment error after 

responding to PS to CS HO request 

8.1 .2 Failure after UE receives HO command 

If the UE encounters a failure at the radio level after it receives the handover command and does not successfully 
transition to 3GPP UTRAN/GERAN RAT, the UE attempts to return to E-UTRAN/UTRAN by sending a re-INVITE to 
the sec AS. The core network (MME, MSC Server) shall take no SR-VCC specific action in the event of not receiving 
the Handover Complete message from the UE. 

8. 1 .3 Handover Cancellation 

If the source E-UTRAN/UTRAN decides to terminate the handover procedure before its completion, the MME/SGSN 
shall return to its state before the handover procedure was triggered. The MME/SGSN attempts to trigger, at the MSC 
Server enhanced for SRVCC, handover cancellation procedures according to TS 23.009 [18]. The MSC Server 
enhanced for SRVCC shall take no SRVCC-specific action towards IMS. 

The MME/SGSN shall also send a session reestablishment trigger notification to UE to start the recovery procedure if it 
receives notification from the MSC Server that the Session Transfer procedure is in progress. Figure 8.1.3-1 shows the 
overall procedure for SRVCC handover cancellation. 
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Figure 8.1.3-1 : SRVCC Handover Cancellation Procedure 

Network has started the SRVCC procedure. SGSN/MME has sent the SRVCC PS to CS request to MSC Server. 

MSC Server is performing the CS HO procedure with target network, and has also started the Session Transfer 
procedure with IMS with STN-SR, see TS 23.237 [14]. 

Source UTRAN/E-UTRAN decides to cancel the SRVCC HO Procedure by sending a Cancel message to 

SGSN/MME. 

Source SGSN/MME indicates SRVCC PS to CS Cancel Notification to MSC Server to start the HO cancellation 
procedure as according to TS 23.009 [18]. 

MSC Server acks the PS to CS Cancel Notification with an indication that Session Transfer procedure is in 
progress. 

Due to the Session Transfer procedure in progress indication, the source SGSN/MME sends a Session 
Reestablishment trigger notification to UE to start the session re-establishment procedure 

UE starts the re-establishment procedure, by attempting to return to E-UTRAN/UTRAN by sending a re-INVITE 
towards IMS for the related session. If the session is no longer active, then this session transfer request shall be 
rejected by the IMS. 



9 Security 

9.1 Network Domain Security with 3GPP2 1xCS IWS 

Network domain security with 3GPP2 IxCS IWS shall be provided by NDS/IP according to TS 33.210 [21] with 
integrity protection and confidentiality. This shall be applied whenever signalling messages (e.g. containing security 
context) are transferred on the SI 02 reference point. 

NOTE 1: In case control plane interfaces are trusted (e.g. physically protected), there is no need to use protection 
according to TS 33.210 [21]. 
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9.2 Network Domain Security with 3GPP UTRAN/GERAN MSG 
Server 

Network domain security with 3GPP UTRAN/GERAN MSC Server shall be provided by NDS/IP according to 

TS 33.210 [21] with integrity protection and confidentiality. This shall be applied whenever signalling messages (e.g. 

containing security context) are transferred on the Sv reference point. 

NOTE 2: In case control plane interfaces are trusted (e.g. physically protected), there is no need to use protection 
according to TS 33.210 [21]. 
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Annex A (informative): 
Determination of Neighbour Cell List 

This annex describes example algorithms for determination of Neighbour Cell List (NCL) for SRVCC operation. In 
case of SRVCC to GERAN/UTRAN it is also clarified when the E-UTRAN includes a SRVCC indication in the 
Handover Required message. 

~AA SRVCC from E-UTRAN to 3GPP2 1xCS 

E-UTRAN may determine the NCL as follows: 

- If the "SRVCC operation possible" indication is set to "true" (i.e. both EPC and UE are SRVCC capable), then: 

- if there is an established QCI=1 bearer for this UE, then Ix cells may be included as candidate target cells in 
the NCL; 

- if there is no established QCI=1 bearer for this UE, then Ix cells are not included in the NCL. 

- If the "SRVCC operation possible" indication is set to "false" (i.e. either EPC or UE is not SRVCC capable), 
then Ix cells are not included in the NCL. 

A.2 SRVCC from E-UTRAN to GERAN/UTRAN 

E-UTRAN may determine the NCL, as well as the need to signal a SRVCC indication, as follows: 

- If the "SRVCC operation possible" indication is set to "true" (i.e. both EPC and UE are SRVCC capable), then 
VoIP-incapable cells may be included as candidate target cells in the NCL, regardless of the presence of an 
established QCI=1 bearer for this UE. Moreover: 

- if there is an established QCI=1 bearer for this UE and the selected target cell is VoIP-capable, then E- 
UTRAN does not include a SRVCC indication in the Handover Required message; 

- if there is an established QCI=1 bearer for this UE and the selected target cell is VoIP-incapable, then E- 
UTRAN includes a SRVCC indication in the Handover Required message; 

if there is no established QCI=1 bearer for this UE, then E-UTRAN does not include a SRVCC indication in 
the Handover Required message; 

- If the "SRVCC operation possible" indication is set to "false" (i.e. either EPC or UE is not SRVCC capable), 
then E-UTRAN does not include a SRVCC indication in the Handover Required message. Moreover: 

- if there is an established QCI=1 bearer for this UE, then VoIP-incapable cell are not be included in the NCL; 
if there is no established QCI=1 bearer for this UE, then VoIP-incapable cells may be included in the NCL. 

a!3 SRVCC from UTRAN (HSPA) to GERAN/UTRAN 

Similar logic may be used as in clause A.2 by replacing E-UTRAN with UTRAN. 
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